home *** CD-ROM | disk | FTP | other *** search
- Path: stc06.ctd.ornl.gov!msr!kennel
- From: kennel@msr.epm.ornl.gov (Matt Kennel)
- Newsgroups: comp.lang.c++
- Subject: Re: External access to private class variables
- Date: 6 Feb 1996 03:26:05 GMT
- Organization: Oak Ridge National Lab, Oak Ridge, TN
- Distribution: world
- Message-ID: <4f6hod$3j6@stc06.ctd.ornl.gov>
- References: <4ermr9$ii7@cloner2.ix.netcom.com> <ENNO.96Feb2203423@kitz.inferenzsysteme.informatik.th-darmstadt.de> <4eu3n7$rbi@clarknet.clark.net>
- NNTP-Posting-Host: msr.epm.ornl.gov
- X-Newsreader: TIN [version 1.2 PL2]
-
- Harlan Messinger (gusty@clark.net) wrote:
-
- > This isn't strange. An object can have several names and be pointed to by
- > several pointers. Making one of those names private hides just that name.
- > It doesn't hide any of the other names, and it doesn't hide the pointers
- > to it.
-
- Well, in my opinion it IS really is strange. Most other OO languages have
- references to objects and nothing but. They may change internal state of
- an object only through the class interface.
-
- > Treating your example for the sake of discussion as real code that
- > someone wrote, all this means is that somebody didn't want the name "x"
- > used to access that spot in memory, but wanted it to be called GSValue()
- > instead. Perhaps GSValue() is a meaningful name for the intended user,
- > and the current implementation of GSValue() is via an integer data
- > member, but perhaps later on it will be via some other private mechanism.
- > If that happens, the change will be invisible to the user, who will still
- > use the public member reference function GSValue() just as before.
-
- That would be fine, as long as you could only do it as
-
- object.GSValue() = 1777;
-
- In this way, I'd still say that you are modifying things by permission of
- the class interface.
-
- But this GSValue() thing can be stored and flung around separately.
-
- cheers
- Matt
-